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Local Area Network (LAN) 
Figure 1. The Basic OAS 



Whether those workstations which make up the database server act as individual and separate 
database systems or cooperate to handle the database management needs of the OAE is an issue. It may 
not be feasible in a given OAE to distribute the database management functionality and load among 
different database servers on the same network, since the OAS is not a distributed database system. More 
likely, the OAE requires a central repository of data and programs that is maintained and accessed via a 
single system, so that the data and programs can be successfully shared throughout the OAE. This calls 
for a database system for centralized databases. 

In conclusion, the overall architectural requirements of a database server for OAEs should therefore 
dictate a centralized database system running on variable and multiple workstations. 

2.2. The Six Characteristics 

There are six major characteristics of such a database server. They are software portability, 
software independence, auto-configurability, survivability, versatility, and performance. Software 
portability provides the database server with the ability to be accessible on a wide range of workstations. 
Specifically, the database server should not be restricted to a particular class of workstations and a 
specific type of operating systems. Instead, it should be portable across a wide range of workstations and 
operating systems of the OAE. If the database server is implemented on multiple workstations, the 
software components of the server running on the separate workstations should be sufficiently 
independent, so that the database server does not become inoperative when a node (i.e., either one of the 
software components on a workstation or a workstation itself) becomes disabled. Software independence 
among system components running on separate workstations may eliminate software and hardware 
interdependencies and the complexity of the database server. 

W’hen running on variable and multiple workstations, the database server should be auto- 
configurable and reconfigurable. W^hen the OAE grows, (i.e., the number of workstations in the OAS 
increases) or shrinks (i.e., some workstations becomes disabled or removed) the database server should be 
able to adjust itself for the addition or loss of workstations. Such adjustment should require no new 
programming and no modification to the existing software. Further, it should incur no disruption of the 
OAE or OAS. The database server should also maintain a consistent and up-to-date copy of the 
database. When a node in the OAE is disabled, it is imperative that the database server still be 
functional, providing continuous, albeit limited, access to the remaining database. This is also the 
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survivability of the database server* 

The database server should also be versatile, providing the user with more than one way of 
accessing the database. In an OAE where there is a large group of individuals from diverse backgrounds 
and with different experiences in using database facilities, the database server should provide different 
database language interfaces in order to facilitate the database user with various ways of accessing the 
database. Finally, the database server should be a database system that is oriented towards providing a 
substantial level of performance. As the time goes by, both the use of and rep>ository in the database 
server increase. To meet the growing needs of the OAE the database server must be able to expand as 
the OAE expands, and still maintain or increase its performance. 

3. THE NEED OF A DATABASE SERVER WITH VARIABLE AND MULTIPLE 
BACKEND CONFIGURATIONS 

3.1. The Proposed Architecture for a Database Server 

We advocate that the architecture of a database server be configured with one controller and one or 
more backends. As shown in Figure 2, the controller and the backends are connected by a broadcast bus. 
When a transaction is received from a workstation, the controller broadcasts the transaction to all the 
backends. Each backend has a number of dedicated disk drives. Since the database is distributed across 
the backends, a transaction can be executed by all the backends in parallel. Each backend maintains a 
queue of transactions and schedules the transactions for execution independent of the other backends, in 
order to ma^jimize its access operations and to minimize its idle time. Thus, different transactions can be 
executed concurrently. On the other hand, the controller does very little work. It is responsible for 
receiving and broadcasting transactions, routing results, and assisting the backends in the insertion of new 
data. By minimizing the work of the controller, we are attempting to reduce the chances that the 
controller may become the bottleneck in the system when the number of backends is increased. The 
backends do all the database operations. Just how' this architecture may have the six characteristics of an 
ideal database server will be expounded in the following sections by way of an experimental database 
system which also exhibits an architectural configuration similar to the one depicted in Figure 2. 

3.2. The Multi-Backend Database System (MBDS) as a Database Server 

To provide a centralized database system, MBDS uses one or more identical workstations and their 
disk systems as database backends and a workstation as the database controller to interface with 
multiple, similar or dissimilar workstations or mainframes. We refer to these workstations and 
mainframes as hosts. User access to the centralized database is therefore accomplished through a host 
which in turn communicates with the controller. Multiple backends are configured in parallel. The 
database is distributed across all of the backends. The database management functions are replicated at 
each backend, i.e., all backends have identical software and hardware. They, of course, have accesses to 
different portions of the database. 
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Figure 2. The Multi-Backend Database System (MBDS) 

There are some key issues to be explored in considering MBDS for OAEs. The current 
implementation of MBDS uses microprocessor-based workstations, Winchester-type disks and an 
Ethernet-like broadcast bus. There are a number of reasons for preferring microprocessor-based 
workstations over the traditional minicomputers. First, the 32-bit microprocesser is quickly attaining a 
reputation as a dependable, versatile and fast CPU, approaching the speed and performance of the 
minicomputers of five years ago. Second, the microprocessor-based workstation is cost-effective. This is 
important when considering that MBDS requires a minimum of two such workstations. It also implies 
that MBDS can be expanded with relative ease and minimal cost by the addition of backend 
microprocessor-based workstations. 

The placement of the user interface is also affected by the use of microprocessor-based workstations. 
The user interface provides access to MBDS and is run from either a separate host, or as part of the 
backend controller. When the user interface is on a separate host, the interface interacts with the 
controller via a bus In either case, the use of a similar (with respect to the controller and backend 
hardware) microprocessor-based workstation for the user interface increases the compatibility and the 
maintainability (with respect to the hardware maintenance and costs) of the database system. 

The final major issue involves the ability of MBDS to support multiple data modcl/language 
interfaces to the multi-backend database system. These multiple model/language interfaces allow the user 
to access MBDS using the relational model/SQL language, the hierarchical model/DL/1 language, the 
entity relationship model/DapIex language, or the network model/CODASYL language. These interfaces 
are also running on either a separate host or the backend controller; and, as such, the issues concerning 
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the user interface also apply here. For a brief introduction to the multi-backend database system MODS 
and the multi-lingual database system MLDS, the reader may refer to jl)emu85a]. 

3.3. Six Characteristics of MBDS for an Effective Role in the OAE 

Regardless of the integration approach that is chosen, MBDS exhibits certain characteristics that are 
desirable in the OAE. These characteristics include the software portability of the MBDS code, the 
software independence of the backend code, the auto-configurability and reconfigurability of MBDS on 
account of its use of identical workstations and replicated software, the survivability of the system 
resulting from the use of duplicated directory data, the versatility of system due to the ability of MBDS 
to support multiple language interfaces, and the performance capabilities of the system as a result of its 
parallel configuration and round-robin data placement. Each of these topics is briefly examined in the 
following paragraphs. 

3.3.1. Software Portability 

The MBDS processes, i e., the controller processes, the backend prc*cesses, and the interface process, 
are all written in the C programming language. C was chosen as the programming language for MBDS 
because of its portability and its reputation as a good systems programming language. We estimate that 
the code of MBDS is about ninety-five percent portable, consisting of 13,000 lines of C code. The five 
percent of system-dependent code involves the inter-process message-passing code on both the controller 
and the baCkends, the inter-computer message passing code for the communications processes, and the* 
disk I/O routines for the record processing process Thus, the majority of the code is portable. In fact, 
some of the implementation development for MBDS takes place on a V'AX-1 1/780 running the Unix: 
operating system, where we are able to take advantage of the C-tools provided by Unix. Thus, we feel I 
that we have designed a relatively portable database system that can run on a wide range of the 32-bitl 
microcomputers on the market today, e.g., the DEC MicroV'AX and the Sun V\’ orkstation. 

3.3.2. Software Independence 

In examining the software independence issue, we focus on the backend processes. The elegance of! 
MBDS is in that the backend software of one backend is identical to the backend software of anotheri 
backend. For logical reasons, the directory data, used by each backend when processing requests, is' 
nevertheless duplicated at every backend. However, the directory data is usually a small percentage of the^ 
non-directory data. Furthermore, the only sharing of information by the backends occurs in one phase of 
the directory search. Otherwise, the directory management, the concurrency control, and the record 
processing processes are independent of each other. So, when a new backend is configured into the 
system, the software present on one backend is simply replicated on the new backend. Additionally, the 
directory data, duplicated at an existing backend, is loaded into the new backend. When bringing a new 
backend into MBDS, we must also decide on whether to rearrange the non-directory data. On the one 
hand, we can redistribute all of the non-directory data across the disk systems of every backend. Thisi 
involves the reloading of data. On the other hand, we can simply leave the data undisturbed, and load 
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only the new data on the new backend. The choice is left to the discretion of the database administrator. 

3.3.5. Aufo-Conflgurability 

One of the most convenient features of MODS is the ability to automatically configure and 
reconfigure the system with ease. When starting the system for the first time, the database administrator 
simply specifies, using an interface, the number of backends in the system MRDS then configures itself 
by notifying the controller and backend processes the number of backends on the system. Using this 
unique feature, MBDS can be reconfigured when a backend becomes inoperable. In such a situation, 
MBDS is configured with one less backend. Conversely, when a new backend is added to the system, the 
system can be configured with one more backend easily. 

3.3.4. Survivability 

MBDS contains only one copy of the non-directory database. When the database is loaded, it is 
distributed evenly across all backends’ disk systems However, the directory data, which contains index 
and cluster information on all data in the database, is duplicated in every backend. The distributed 
directory data, coupled with the software independence and reconfigurability of MBDS, offers an increased 
survivability of the database system in the OAE. If a backend or backends become inoperable, the system 
is still usable. While a backend is inoperable, a log of transactions that modified both the directory and 
the non-directory data is kept. When the backend is reconfigured into MBDS, the log is run for the 
purpose of updating the directory and other data. Although portions of the non-directory data become 
inaccessible with the inoperable backends, MBDS can still access and retrieve the rest of the data. 
Incomplete data is better than no data, provided that the user is informed of the situation. 

3.3.6. Versatility 

One of the biggest advantages of having MBDS as part of an OAS is the ability of MBDS to provide 
support for multiple data models (and therefore data languages) through the use of multiple language- 
based interfaces. In the OAE, where users are from diverse backgrounds, such a utility is a unique feature 
in a database management system. In fact, the language interfaces can be tailored by the workstation. 
One workstation could have a SQL interface, another a DL/I interface, a third a Daplex interface, and yet 
another a CODASYL interface. By tailoring the language interfaces by workstation, the software required 
for each interface process could be reduced. Conversely, with a wide range of language interfaces 
available at every workstation, the workstation becomes more accessible to a wide range of users. 

3.3.6. Performance 

The performance capabilities of any DBMS are important in an OAE, since the DBMS tends to 
serve as a repository of all the permanent data and programs of the OAE. As the repository becomes 
large and the database activities increase, the DBMS as a database server may become the performance 
bottleneck. However, MBDS is specifically designed to provide for capacity growth and performance 
enhancement. The performance metric of major concern is the response time of a request. The rtiponst 
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Ume of a request is the time between the initial issuance of the request and the receipt of the final results 
for the request. MBDS has two original design goals. First, if the database capacity is fixed and the | 
number of backends is increased, then the response time per request reduces proportionately. For | 
example, if a request had a response time of 60 seconds when there was one backend, the same request 
should have a response time of nearly ?>0 seconds when there are two backends, and of nearly 15 seconds 
when there are four backends, provided that the database size has remained constant. 

The second goal is that, for the same requests, if the response sets are increased due to an increase of 
the database size and the number of backends is increased in proportion to the increase of response set, 
then the response time per request remain the same. For example, if a request had a response time of 60 
seconds when there was one backend with 1000 records in the response set, then the same request would 
have a response time of close to 60 seconds when there are two backends and 2000 records in the response | 
set. 

The underlying concept in each goal is that MBDS in the OAE would supply a database system 
that would grow as the OAS grows, and would either maintain a constant response time per request by 
’growing* its backends or halve a given response time per request by ’doubling’ its backends. On the basis 
of our preliminary analysis, the operational MBDS can indeed meet the two goals. The analysis is also • 
published and documented in |Demu85b, Demu85c, Teka84). 

4. THE INTEGRATION OF MBDS INTO THE OAE 

In this section, we first focus on the ways to integrate MBDS into the OAE. In this focus, we 
consider five possible configurations as candidates for integrating MBDS into the OAE. Our second focus 
examines the relative advantages/disadvantages of the integration configurations. In the examination, 
we are interested in presenting an intuitive comparison of the five configurations. 

4.1. Five Approaches to the Integration of a Database Server 

Recall that the basic OAS, consists of a group of workstations, connected by a local-area network 
(LAN) such as an Ethernet |Metc76|. Such a design has been shown in Figure 1. Given this basic 
characterization, we now consider the integration of MBDS into the OAS. In the first approach, MBDS is 
added on as a separate group of workstations in the OAS, with its own LAN. We characterize this 
approach as the non- integrated dual-LAN design. In this approach, the additional workstations are 
dedicated to the database operations. As such, they are inaccessible for non-database activities. We 
provide the interface process (which may include one or more language interfaces) as a part of the user- | 
accessible workstations, i.e., hosts. The resulting OAS is shown in Figure 3. In this and the remaining ! 
four approaches, the placement of the interface software (i.e., the number of hosts and which hosts have 
the interface software) is left to the discretion of the database administrator. i 
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Figure 3. The Non-Integrated Dual-LAN Design 

The second approach is the nori’ integrated tingle^ LAN design. In this approach, as shown in Figure 
4, MBDS and the OAS share a common LAN. However, the MBDS controller and backends still remain 
as separate workstations in the OAE. 
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Figure 4. The Non-InLegrated Single-LAN Design 



The third approach, the partially- integrated design, integrates and replicates the backend software as 
permanent background processes into some of the OAS workstations. The remainder of the MBDS may 
have the backend software replicated in user-inaccessible workstations. The distribution of the backend 
software within the user workstations is controlled by the database administrator in the OAE. The 
controller is the key component in MBDS, and is devoted to overseeing the management of the database 
system. Therefore, the controller software is placed in a separate workstation, that is not directly utilized 
in the OAS. The partially-integrated design is shown in Figure 5. 
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Figure 5. The Part i al ly -Integrated Design 



In the fourth approach, the iaolattd- controller design, the MBDS backend software is integrated and 
replicated into the existing workstations. As in the partially-integrated design, the controller software is 
implemented in a user-inaccessible workstation. The backend software is installed as permanent 
background processes in one or more workstations. The isolated-controller design is shown in Figure 6. 




Figure 6. The laolated-Controller Design 



In the fifth approach, the fullg- integrated design, the MBDS software is completely integrated into 
the OAS. The controller software is installed as permanent background processes on one workstation. 
The backend software is installed and replicated as permanent background processes on one or more 
workstations. The fully-integrated design is given in Figure 7. 
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Figure 7. The Fully-Integrated Design 





- 10 - 






In the non-integrated dual-LAN design, we are using the LAN as a logical two-way communications 
device for MBDS. Messages are passed from the interface process of a particular workstation to the 
controller and from the controller back to the interface process. In the remaining four designs, we are 
using the LAN as a logical fiv^-way communications device. Messages are passed from the interface 
process to the controller, from the controller to the backends, between the backends, from the backends to 
the controller, and from tlie controller back to the interface process. 

4.2. A Comparison of the Five Designs 

Informally, let us consider the trade-offs resulting from one approach to another, which depend on 
various performance and cost considerations. The non-integrated approaches differ only by the cost of a 
LAN, but the corresponding performance gains of the dual-LAN approach probably outweighs the cost of 
the extra LAN. In particular, the load on the LAN for the OAS is significantly lower in the dual-LAN 
design. However, in both these approaches, a high price is paid as the database and transactions of 
MBDS grow in size and intensity. The integration of more backends into MBDS and therefore the OAS is 
costly, since the new workstations are only accessible to the database management system. 

In such a situation, either the partially-integrated design or the isolated-controller design becomes 
an attractive alternative. In either case, keeping the controller on a non-accessible workstation is a good 
choice for performance. In the partially-integrated design, as the database grows, more user workstations 
can be configured into the database system. Further, if a workstations is entirely devoted to either the 
backend software or the OAS software but not both, additional workstations can be easily added to either 
MBDS or OAS. Thus, in the partially-integrated design, these workstations can be added as either 
dedicated database backends or user workstations. Again, in either case, the addition of more backends 
into MBDS is more cost-effective, even if the backend software is added as part of the user workstations. 
We feel that the fully-integrated design is the least desirable. The controller as part of a user-accessible 
workstation would substantially degrade the performance of MBDS as the non-database use of the 
workstation at which the controller resides increases. 

Overall, the non-integrated dual-LAN design may yield the highest performance and have the 
greatest cost. (See Figure 3 again.) The performance of the non-integrated single-LAN and partially- 
integrated designs are about the same. However, the partially-integrated design is more versatile in 
performance gain and is still cost-effective. The isolated-controller is not versatile in performance, 
although it excels in cost-effectiveness. Finally, while the fully-integrated design is cost-effective, its 
performance may leave a lot to be desired. 

5. THE ANALYSES OF THE FIVE INTEGRATION DESIGNS 

In this section we provide an examination and analysis of the five configuration designs presented in 
Section 4.1. Our basic intent is to provide a framework by which the configurations presented earlier can 
be analyzed and compared. In the process, we can determine just how well our intuitive comparison in 
Section 4.2 measures up to a queueing model analysis of the configurations. 



In order to compare the five approaches to integrating MBDS into an office automation 
environment, we use simple queueing models for single and multiple devices. To avoid the possible 
confusion in the use of the term ’server’, we refer to the servers of queues as devices. An analysis of the 
message types in the five approaches indicates that both the single- and the multiple-device models must 
be applied to each approach, due to the variety of workstations in each configuration, (i.e., we have 
several workstations, several backends and one controller in the configurations). Whether the controller is 
dedicated or incorporated into a workstation is taken into account in the analysis. 

As mentioned in Section 4.1, the local-area networks are used either as 2-way logical communication 
devices as in the dual-LAN design or as a 5-way logical communication device in the other four single- 
LAN designs. To reduce the complexity of the queueing analysis, we assume that the backends do not 
communicate with each other; a similar assumption holds for the workstations. These assumptions are 
reasonable. In other words, we limit the communication paths in the configurations to: workstation-to- 
controller, controller-to-backend, backend-to-controller, and controller-to-workstation. 

However, this does not necessarily limit the actual message types that are present in each of the five 
configurations. By examining the operational aspects of the five configurations we note that there are five 
distinct types of devices; workstation (W’), backend (B), controller (C), workstation-backend (WB), and 
workstation-controller (WC). In the WB device, the workstation functions are combined with the 
backend functions. (See Figures 5, 6, and 7 again.) In the WC device, the workstation functions are 
combined with the controller functions. (See Figure 7 again.) Given this characterization, we can 
summarize the distinct message types for each of the five configurations. These are presented in Table 1. 

Let us briefly explain the notation used in Table 1. The entities on the right of the arrows represent 
the devices which receive and service the message. The entities on the left of the arrows represent the 
origin of the message. For example, W == = = > C, is a message that is serviced by the controller (C) and 
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Table 1. A Summary of Message Types 



is received from a workstation (W). Compound letters (e g., WB, BW, and CW) are used to represent an 
integrated workstation. The first letter in the abbreviation indicates the part of the integrated unit that 
is intended as the originator or recipient of a message. In our analysis, we assume that each message type 
has a distinct message service time associated with it. 



5.1. The Queueing Equations 



In order to apply simple queueing theory to the problem at hand, we must continue to add to our 
list of assumptions. In particular, the following assumptions need be made; the inter- arrival times of 
messages follows a Poisson process, the service times of messages are exponentially distributed, and the 
items in the queue are serviced on a first-come-first-serve (FCFS) basis. All of these assumptions are used 
to simplify the queueing equations that are used to evaluate and compare the five configuration designs. 
In our queueing analysis, we are interested in calculating the waiting time of individual devices and the 
total waiting time of all devices. The waiting time of individual devices, is the time spent by an item in a 
queue of a particular device type before the item is serviced. The total waiting time of all devices is the 
sum of the waiting times of an item for all of the devices. Now let us proceed with the specification of the 
queueing equations (i. e., the waiting-time equations) for the single- and multiple-device models. 

For the single-device model, given the average service time (< ) and the average number of messages 
(n), the average number of items waiting to be served is given by the equation, = — - — , where p is the 

1-p 

device utilization and is equal to n . The waiting time in the queue is given by t^ = — . 



In the multiple-device model, if there are M identical devices, the average number of items waiting 



to be served is given by w = B x 
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I - pA 



and 



A 




The waiting time is, as before, given by t^ 



— 

n 



Depending on the 



particular message type, we apply either single-device or multiple-device queueing theory and obtain the 
corresponding equations for the waiting time. In either the single- or multiple-device model, we use the 
individual waiting times to calculate the total waiting time, , where t^ . 

ail dev$ft* 



In order to specify the queueing-time equations (i e., the total waiting time) for the five different 
configurations, we must add once again to our list of assumptions. In particular, we assume the following: 



(1) . There is a maximum of, k , workstations, irrespective of whether a 
workstation is integrated or not with a backend or controller. Each 
workstation generates a total of a messages. In other words, the number 
of workstations and the number of messages generated by a workstation 
are fixed. 

(2) . There is a total of, m, backends. If n of these are dedicated 
backend workstations, then there are (m-n) integrated workstations 
and (it— (m-n)) dedicated workstations. Each backend generates a 
total of 6 messages. 
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(3) . There is exactly one controller. If the controller is integrated into a 
workstation, then the number of dedicated workstations is reduced by 
one. The controller does not generate any messages of its own and thus 
merely acts as a relaying mechanism for message types between the 
workstations and the backends. 

(4) . .Associated with each distinct device type is a unique message 
processing time. We call this time the service time. These service times 
are represented as subscripted quantities, viz., 5^ etc. 

(5) . Unless otherwise specified, all performance parameters in the 
equations represent average values. 

The total waiting-time equations for the five configurations are given in the Appendix. 

6.2. A Queueing Analysis of the Five Designs 

To obtain a quantitative determination of which of the configurations is better suited to an office 
automation environment, we compute the total waiting time for each of the five configurations. We begin 
by assuming that the workstations generate a fixed number of queries and that the backends generate a 
fixed number of responses. Next, we determine the values for the variables that have been listed in the 
previous section. Specifically, we must assign values for A: , m , n , o , b and the service times. For our 
analysis, we pick A: = 4,m=2, o = l, and 6 = 1. The number, n , of dedicated backends will vary, 
depending on the configuration. For the service times, we choose 
~ ~ ^WC - ^ - O F 

Given' this scenario, we can now present a synopsis of the device structure in each of the five 
configurations. This synopsis is presented in Table 2. Briefly, let us examine the distribution and 
functionalities for the devices in each configuration. In both the non-integrated single-LAN and dual-LAN 
designs, there are a total of seven devices, with 4 dedicated workstations, 2 dedicated backends, and 1 
dedicated controller. The partially-integrated design has six devices, with 3 dedicated workstations, 1 
device having both the workstation and backend functions, 1 dedicated backend, and 1 dedicated 
controller. In the isolated-controller design, there are five devices, with 2 dedicated workstations, 2 
devices having both the workstation and backend functions, and 1 dedicated controller. Finally, in the 
fully-integrated design, there are four devices, with 1 dedicated workstation, 2 devices having both the 
workstation and backend functions, and one device having both the workstation and controller functions. 



Configuration 


Device Distribution 
and Functionality 


Non-lntegrated Dual-LAN 


”Tvv 


““2 B 


1 C 


Non-Integrated Single-LAN 


4 W 


2 B 


1 c 


Partially-Integrated 


3 W 


1 WB 


I B 1C 


Isolated-Controller 


2 W 


2 WB 


1 C 


Fully-Integrated 


1 W 


2 W'B 


1 WC 



Table 2. The Device Structure 
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Using this device structure and working with the variable values defined above, we can calculate the 
total waiting times for each of the five configurations using the equations in the Appendix. The computed 
results for the total waiting times are summarized in Table 3, where is the total waiting time and 
T \ is the total waiting time that is common to all of the configurations. 



Configuration 


T - T ' 


Non-lntegrated Dual-LAN 


0.04 


Non-liitegrated Single-LAN 


0.042 


Partially -Integrated 


1.58 


Isolated-Cont roller 


0.051 


Fully-Integrated 


0.282 



Table 3. The Total Waiting Times 

Based on the numerical results presented in Table S, it can be seen that the dual-LAN configuration 
has the best performance. This is to be expected since the dual-LAN structure allows for the concurrent 
processing of messages between the hosts and the controller on the one hand, and between the backends 
and the controller on the other. Of the remaining four, the non-integrated single-LAN performs the best, 
barely outperforming the isolated-controller configuration. Surprisingly, the isolated-controller 
configuration seems to outperform both the fully-integrated and the partially-integrated configurations. A 
plausible explanation is that the isolated-controller configuration has fewer distinct message types than 
either the fully-integrated or the partially-integrated configurations. (See Table 2 again.) For similar 
reasons, the fully-integrated configuration outperforms the partially-integrated configuration. Overall, we 
observe that the intuitive comparison in Section 4.2 has been generally accurate, with the exception of the 
partially-integrated design. 

6. CONCLUSIONS 

We have shown how MBDS can play an important role in the OAE as an database server. 
Specifically, we have shown how MBDS can provide both traditional and new database support. We have 
also shown why and how MBDS should be integrated into an OAS, i.e., what MBDS has to offer to an 
OAE. In particular, MBDS can be integrated into an OAS in a number of ways, depending upon the 
needs of the office automation environment. Once MBDS is configured in an OAS, the reconfigurability 
feature, coupled with the replicated backend software, permits the database server to grow as the needs of 
the office information system grow. Additionally, when MBDS expands, the response time per request 
for the system decreases proportionately, as long as the database size remains constant. As the database 
grows in size and consequently the responses, MBDS can maintain the response time for the same type of 
database services by expanding its backends. 

As a multi-lingual database system, MBDS offers the ability to access the database using a variety 
of language interfaces. From the native data language of MBDS to sophisticated data languages such as 
SQL, Daplex, CODASYL and DL/I, the user can select a language to query the database. The high 
degree of software portability exhibited by MBDS, allows the system to be implemented on a wide range 
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of microcomputers, offering database support for a wide range of office automation systems. Overall, we 
feel that MBDS is close to an ideal database server for the office automation environment. 

At the queueing analysis level, we still have some work to do. The queueing analysis presented in 
Section 4 has been preliminary, and we are currently pursuing a more complete analysis of the five 
configurations. Among other things, we hope to ascertain how' well each configuration performs under 
different assumptions, i. e., for different values of the queueing variables. VVe would alsr‘ like to determine 
when the performance of a particular configuration begins to degrade, given an increase in the number of 
devices in the configuration 

Finally, we must also investigate the other relevant considerations when choosing a particular 

configuration for a specific OAE. Basically, the choice of a configuration depends not only on 

quantitative data of the configurations’ performance, but on external considerations, such as the 
environment into which the database server is integrated. If an GAS consists of a fixed number of 

workstations, say two, and there is no grow th of the system in terms of additional workstations, then the 

logical choice is to adopt the fully-integrated approach where the controller is on one workstation, the 
backend on the other, and the database interfaces on both. If, instead, the OAE is large enough to 
demand a dedicated database server, then the logical choices are either the non-integrated single-LAN or 
dual-LAN approach. 
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APPENDIX. THE TOTAL WAITING TIME EQUATIONS FOR THE FIVE 
CONFIGURATIONS 

In this appendix we provide a synopsis of the total waiting time equations used for each of the five 
configurations that have been proposed in Section 4. These equations were used to calculate the data 
presented in Table 3. In the equations below, k is the number of workstations, dedicated or not, m is the 
number of backends, dedicated or not, n is the number of backends, and 5 is the service time. The total 

waiting time is ^ t^ . 

ail de9tce$ 

The total waiting time for the non-integrated dual-LAN configuration is: 



max ( kS^/ (1 - kS)y m5^/ (l - m5 ) ) -I- 
max ( Bi/ (m - kS], B 2 / ~ ) ) 

(ib5)"/ m! 



where B \ = 






m 



f = 0 



and B 2 = 



(m5)V k} 



^ - ft ^ • 



1*0 
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The total waiting time for the non-intcgrated sin*gle-LAN configuration is: 



/ (1 kS ) mS^/ (1 - mS ) 4 B i/ (m - kS ) -^ B-ii (k — mS ) 



where and B 2 are as above. 

The total waiting time for the partially-integrated configuration is: 
kS^/ (1 - ib5) 4 m5V (1 - H BJ (n - A:5 ) 4 
B 2 I ("» - « - it5 ) 4 B^l (^ - m 4 n - m5 ) t B (m - n - m5 ) 

n ! 



where B | = 



(*5)" / "! + (1 - — )"E-^’ 



1=0 



and fl 2 = 



(kSr-"l (m-n)! 



(*5)-"-"/ (m-n)! + (1 - 

m-n •• 



and B^ = 



(mS)*""-^"/ (Jb -m 4 n )! 



(mS)*-"*^"/ (k-m+n )! 4 (1 - 



it-m 4 n^ i=o *■ 



and 84 = 



(m5)’"-y (m-n)! 



(m5)"*-'*/ (m-n)! 4 (1 - 



#•» 



The total waiting time for the isolated-controller configuration is: 
kS^/ (1 — ik5) 4 mS^j (1 — m5 ) 4 B|/ (m - ik5 ) 4 
B 2 I [k — m - mS ) 4 fl 3 / (m — mS ) 



where B j = 



and flo = 



(ib5)^/ m! 



(tS)" / m! 4 (1 - 

.=0 •• 



(m5)*-'"/ (k-m)l 



u , >n5 * (m5)' 



(m5)*-'"/ (*-m)! 4 (l - 



it - r?i 



) E 



I =0 



and Bj = 



(m5)^/ m! 

(msr/ m! 4 (1 - 5)E:‘-^^ 

1=0 * • 



The total waiting time for the fully-integrated configuration is: 
it5V 11 - kS) -h mS^/ (1 - m5) 4 B,/ (m - it5 ) 4 
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B (rn - rn5 ) -f B^/ (A: — rn — 1 — mS ) 



where 



and /?2 



and i?3 



^ = 



(ib5)"*/ f7i! 



(m5)"’/ m! 



m “ 1 1 C \ • 

(m5)'” / m! -f (1 - 



I ^0 

\k - n 



(rn5)*~"~'/ {k-n-l)\ 



(mS)‘-"-V (t-n-l)!+ (1 - 

fc-n-l t! 
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